Subject: Questions Raised During AIW 6/28/94

From: "David D. Chen ((919)-254-6182)" <[email-masked]>
Date: Mon, 11 Jul 94 07:38:30 EDT

Since I haven't seen any comments regarding to any of the questions
raised during AIW meeting 6/27/94, I would like to post my view.
(It is important to express your view, if consensus is to be sensed
via mailing list.)

Item 1: Should the MIB allow more than one DLSw entities?
  I think the MIB should only allow one DLSw entity.  It simplifies
  the MIB and satisfies most of implementations.  For those who
  definitely have the need of running multiple DLSw entities in the
  same box, I suggest that the technique of community name should be
  used to distinguish them.  It seems to me that one of the key
  reasons that running multiple DLSw's is separated one from the other.
  It seems for the same reason, management of one should be separated
  from the other.  Technique of community name can be used just for that.

Item 2: Should the MIB allow transport connections other than TCP/IP?
  yes, I would say.

Item 4: Should the MIB be designed for configuring data link switches?
  yes, I would say.  Of course, there are implementation specific
  configuration stuff.  So, I would expect that enterprise specific
  configuration objects to supplement for each individual implementation
  needs.

Item 6: One set of Capabilities Exchange for all, or partner dependent,
        ...
  To simplify and meet most of implementation's need, I would say one
  set for all (the whole box).  Enterprise specific MIB can be
  developed for other needs.  (And partner's MIB should also be able to
  tell what has been exchanged.)

Other items (between 1-13):
  These are all good objectives which we should try to accomplish.

Dave Chen
IBM Corp.

---

From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
Date: Mon, 11 Jul 94 12:12:12 PDT

My comments are marked with AKB>

Regards,

Alan

--- Begin (edited) Included Message ---

AKB> The MIB should only allow for one entity and I don't think there
AKB> should be any text about community names as a technique (if vendors
AKB> use that method, or any other, we should not specify the method
AKB> as part of the standard).

AKB> The MIB should use pointer to other MIB table entries to allow
AKB> for other Transport, Network, or Data Link layers (as long as it
AKB> can pass error free, sequenced frames, in theory SSP could be modified
AKB> to run on top of it).  There may be some specifics for TCP that
AKB> may prevent you from doing this however.

AKB> Watch out for number of MIB vars, usually configuration will
AKB> require both Admin and Oper tables which increase the total number 
AKB> of objects.

AKB> What do you mean by One set of Capabilities Exchange / partner
AKB> dependent??  One set that everyone implements??  If that is so
AKB> then you should at least try to attain it.

Dave Chen
IBM Corp.
    
--- End (edited) Included Message ---